-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[APM] Instrument beat pipeline #17938
Conversation
and some basics for the elasticsearch output
also makes transaction end more resilient
Hey, can anyone have a look at this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Added some food-for-thought comments.
@@ -94,8 +104,7 @@ func (w *clientWorker) run() { | |||
continue | |||
} | |||
w.observer.outBatchSend(len(batch.Events())) | |||
|
|||
if err := w.client.Publish(batch); err != nil { | |||
if err := w.client.Publish(context.TODO(), batch); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps leave a // TODO
comment as well, explaining what needs to be done?
data []publisher.Event, | ||
) ([]publisher.Event, error) { | ||
func (client *Client) publishEvents(ctx context.Context, data []publisher.Event) ([]publisher.Event, error) { | ||
span, ctx := apm.StartSpan(ctx, "publishEvents", "output") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be better if we didn't create this span, and just relied on the "publish" transaction, but this is probably necessary for now if we really want the labels.
Ideally, the code for recording the labels (events_original
, etc.) should be done in a single location, rather than in specific output implementations. This would at lease give high-level information for all outputs. Specific outputs could optionally extend those spans with output-specific information, or add sub-spans (e.g. the apmelasticsearch span).
I think to do that we'd need to change the Batch and/or Observer interfaces (to report batch-specific stats) and/or the Publish signature (to return the stats).
@urso @ycombinator any more comments? |
Hey @jalvz, the |
One thing that just occurred to me (sorry!) is that we're instrumenting code in the So now I'm wondering if it's a good idea to add instrumentation inside this package or if we should try to instrument around the calls into this package (which would primarily be the |
Ah, I see. I'm happy to move up the the instrumentation if you prefer... that said, without |
Yeah, as things stand today I think the changes in this PR are not really a problem. That's because it looks like the only point of instrumentation (correct me if I'm reading this wrong, btw!) is inside the I'm more wondering what this means going forward, when we try to pull out WDYT? |
Yes, exactly. Like, nothing doesn't break or anything if not done, but we would get the value there in doing it. I added a comment about that (great idea). |
@@ -130,6 +130,8 @@ func NewConnection(s ConnectionSettings) (*Connection, error) { | |||
} | |||
|
|||
var httpClient esHTTPClient | |||
// when dropping the legacy client in favour of the official Go client, it should be instrumented | |||
// eg, like in https://github.com/elastic/apm-server/blob/7.7/elasticsearch/client.go |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM; merge when CI looks good.
Looking forward to seeing the results of this instrumentation — thanks for doing it!
fantastic, thanks a lot! |
Merging this now, thanks all again for review! |
This allows beat users to instrument the publishing pipeline by setting ELASTIC_APM_ACTIVE=true in the environment. Co-authored-by: Gil Raphaelli <gil@elastic.co> Co-authored-by: Andrew Wilkins <axwalk@gmail.com>
* [APM] Instrument beat pipeline (#17938) This allows beat users to instrument the publishing pipeline by setting ELASTIC_APM_ACTIVE=true in the environment. Co-authored-by: Gil Raphaelli <gil@elastic.co> Co-authored-by: Andrew Wilkins <axwalk@gmail.com>
What does this PR do?
Instruments beats publishing output and the elasticsearch output.
Why is it important?
To gain insight into performance of libbeat based applications.
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.How to test this PR locally
Run any beat with ELASTIC_APM_ACTIVE=true set in the environment
Related issues